net-gateway: tag TLS handshake failures with the peer's alert - #708

Problem

gateway.tls.handshake has an alert tag, but TlsFailure::new always set it to none and nothing ever filled it in. A guest that rejects the interception chain (sends unknown_ca / bad_certificate) was recorded exactly like a guest that disconnects or resets mid-handshake: outcome:error, reason:io, alert:none.

Change

• When a handshake (or an established inspected connection) fails, read the fatal alert the peer sent. tokio-rustls returns an io::Error wrapping rustls::Error::AlertReceived(desc).
• Tag it with the alert's numeric wire value from RFC 8446 §6, for example alert:48 (unknown_ca), alert:42 (bad_certificate) or alert:46 (certificate_unknown). The value fits in one byte, so the tag is bounded.
• none still means the peer sent no alert.
• The tls_alert log field on tls_handshake_error, gateway_boundary_failure and tls_connection_error carries the same number.
• reason and every other tag are unchanged.
• Removed the unused alert_class field.

The tag reports alerts the peer sent. Alerts the gateway itself sends (for example when origin certificate verification fails) aren't surfaced by rustls in a general form, so they're out of scope here.

Validation

• cargo fmt --all -- --check passes.
• cargo clippy -p pplx-space-net-gateway -p pplx-space-metrics --all-targets -- -D warnings passes.
• Gitleaks on the staged diff found nothing.
• No tests added.

Rollout note

This doesn't add a new metric or tag key; the alert tag just gets new values. If a deployment allowlists tags for gateway.tls.handshake, alert must be on that allowlist.